-
Notifications
You must be signed in to change notification settings - Fork 25k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add augmentation #19003
Add augmentation #19003
Conversation
Indeed! I can have a look at some of those once this is in. Lots of them aren't really good, but a few will be helpful. |
@@ -217,7 +219,15 @@ public MethodType getMethodType() { | |||
// otherwise compute it | |||
final Class<?> params[]; | |||
final Class<?> returnValue; | |||
if (Modifier.isStatic(modifiers)) { | |||
if (augmentation) { | |||
// virtual/interface method disguised as static |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
static method disguised as virtual?
also for the map apis, we should make a choice whether they should be BiFunction/BiPredicate like i have them here, or just Function/Predicate but taking the Map.Entry. Its the difference between:
and
I really have no strong opinions, but in the scripting api its nearly impossible for me to tell what is a map and what is a list. By requiring lambdas on maps to take two parameters (key, value), if things are wrong it will be very clear. This is also consistent with the apis java has on Map. On the other hand it means parentheses... |
LGTM! @rmuir Thanks for doing this! |
I prefer the BiFunction version because it has you name the key and value something interesting and you rarely ever need a Map.Entry from one of those. |
ok lets stick with it. we can always change it. The BiFunction has the advantage of providing the clearest error messages and least confusion, because arity gives us that (even if types are murky). |
This adds the ability to have additional methods to whitelisted classes. These are just static methods taking the receiver as the first parameter. There isn't a performance hit or anything.
I added a few of groovy's enhancements to the collections api (e.g. maps n lists) to make those easier to work with. These are things such as
each
,collect
, and so on that can be less verbose than java streams apis. Closure parameters were just swapped out for the appropriate java functional interface.We may want to do more of them, candidates IMO would be around CharSequence/String/Pattern, to make manipulation easier for update scripts/ingest/etc.
This replaces the previous
aliases
functionality (which didn't work quite right in some cases) and ensures that these methods work in all situations (e.g. target of a method reference and so on). The aliases are just accomplished this way instead.